Add storage for forwarded payments #772
Add storage for forwarded payments #772benthecarman wants to merge 3 commits intolightningdevkit:mainfrom
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
benthecarman
force-pushed
the
save-fwd-payment
branch
from
1feb7ae to
ba15c40
Compare
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
Thanks! I do wonder if we should really enable storing all forwards by default, or rather make this optional.
Also more generally I wonder if users really expect us to store all forwarded payments forever, or if we should only keep the last X entries in the store? Also, with general-purpose HTLC interception coming up, maybe storing forwards might even be something we entirely want to leave entirely to the user after all?
What do you think?
benthecarman
force-pushed
the
save-fwd-payment
branch
from
ba15c40 to
20877bd
Compare
|
Addressed comments. I think this makes sense to include in ldk-node and not just leaving it up to the user. If we are focusing on LSPs this will be an essential feature, especially if we want to add accounting tools down the line. I think it can make sense to disable this and/or add a function to prune the storage for it. Maybe just an option that tracks totals per channel rather than individual htlcs |
| } | ||
|
|
||
| /// Retrieves all forwarded payments. | ||
| pub fn list_forwarded_payments(&self) -> Vec<ForwardedPaymentDetails> { |
There was a problem hiding this comment.
This makes we wonder if we should wait for lightningdevkit/rust-lightning#4347 (and some follow-up PRs for implementations here ) to land so this can directly use pagination from the start?
There was a problem hiding this comment.
I figured we weren't doing a release until the next ldk release so that'd be a given but can hold off on it if that's not the case
benthecarman
force-pushed
the
save-fwd-payment
branch
from
20877bd to
ae3b74b
Compare
Routing nodes and LSPs want to track forwarded payments so they can run accounting on fees earned and track profitability across time. We now store these to make it easier to track and allows for future accounting utils in the future. This shouldn't effect edge user nodes as they should never be forwarding payments. Implementation is mostly just copied how we currently handle normal payments and adapted for forwarded payments.
benthecarman
force-pushed
the
save-fwd-payment
branch
from
ae3b74b to
970a395
Compare
Track aggregate stats (fees earned, payment counts, amounts) per channel. Add ForwardedPaymentTrackingMode config: Stats (default) for lightweight metrics only, or Detailed to also store individual payment records. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
benthecarman
force-pushed
the
save-fwd-payment
branch
from
970a395 to
c3f7714
Compare
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
IMO storing granular forwarding information long-term is dangerous. Instead, can we store information that allows for easier compaction? eg total forwarding on a per-X basis between channel pairs?
Agree it's not great to store everything forever. However, it's also hard to guess which values users are interested in. For example, one metric they def. want to see is fee revenue, and I suspect they might even want individual values for each payment forwarded rather than aggregated numbers. |
|
I started working on a version where you set an interval, say 12 hours, and we store individual events and after the time has lapsed we combine them into a single entry. Does that sound good? |
Yea, I kinda wonder what kind of aggregate stats they might want. Pairwise totals and counts over discrete time horizons suffices for things like "average forwarded per payment over this channel pair", but median is of course trickier. Maybe that's okay? |
I think its totally fair to store the last N hours of individual forwards, yea! After that question is format. |
4 participants
Routing nodes and LSPs want to track forwarded payments so they can run accounting on fees earned and track profitability across time. We now store these to make it easier to track and allows for future accounting utils in the future.
This shouldn't effect edge user nodes as they should never be forwarding payments.
Implementation is mostly just copied how we currently handle normal payments and adapted for forwarded payments.